1. Field of the Invention
The present invention generally relates to a bus bridge. More particularly, the invention relates to a bi-directional bridge for use with buses in which multiple devices may attempt to drive the bus concurrently. More particularly still, the invention relates to an I2C bus bridge.
2. Background of the Invention
Modern computer systems generally include a plurality of devices interconnected through a system of buses. For example, a conventional computer system typically contains one or more central processing unit (CPUs) coupled through a host bridge to a main memory unit. A CPU bus usually couples the CPU(s) to the host bridge, and a memory bus connects the bridge to the main memory. The host bridge typically includes a memory controller which receives memory access requests (such as from the CPUs) and responds by generating standard control signals necessary to access the main memory.
Other types of buses may also be present in a computer system. The I2C bus developed by Philips is one such example. The I2C bus generally has a simple architecture, is easy to use and is thus becoming widely used. The I2C bus has one or more characteristics that may also be found in other buses now known or later developed. One such characteristic is that only a limited number of devices can be connected to any one bus. This limitation results from electrical loading and noise concerns. Accordingly, if the number of I2C-compliant devices desired to be included in a system increases, a system designer is forced to include more than one I2C bus in the system. It is not uncommon today for a system to have multiple I2C buses with each bus having one or more devices connected thereto.
It may be desired for a device attached to one I2C bus to communicate with a device attached to another I2C bus. One way to permit this communication, albeit in a less than efficient manner, includes using the core logic of the system (e.g., the host processor) to pass information from one I2C bus to another. Another technique would be to bridge the two I2C buses together.
The bridge solution is not simple and straightforward because of another characteristic of the I2C bus in which more than one device attached to the bus may attempt to drive the bus at a time. Concurrent bus assertion is common during the I2C bus arbitration process, for example. Also, slave devices may attempt to drive a bus while a master is driving the bus in order to cause the transaction to stall for one reason or another. When a device drives the bus, the device typically pulls one of the bus signals low. Another device may drive that same signal low. Because a second device is driving the signal low, the signal will remain low even if the first device releases the signal. This is generally true because of the open-collector or open-drain nature of the I2C bus. This characteristic makes it difficult to bridge two I2C buses together.
An example will help clarify the problem. A bridge may couple together two I2C buses (designated A and B). If a master on bus A drives the clock signal low, the bridge should detect that event and drive the corresponding clock signal low on B bus. If, while the B bus clock signal is low, a device on the B bus attempts to force low that already low clock signal, the bridge will not be able to detect this occurrence because the clock signal is already low. Then, if the master on bus A that initially drove the clock signal low releases its hold of the clock signal and the bus B device is still driving bus B's clock signal low, the bridge will not know to keep the bus A clock signal low.
A solution to this problem is needed. Such a solution preferably should be inexpensive to implement.